-
Notifications
You must be signed in to change notification settings - Fork 14
CLOUDP-295785 - staging support for image building #336
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
Fix build scenario Remove create and push manifests Continue improvement to main Simplify main and build_context missed Pass Build Configuration object directly Use legacy and new pipeline Fix Remove --include Rename MCO test image Multi platform builds, with buildx TODOs Implement is_release_step_executed() Fix init appdb image Import sort black formatting Some cleaning and version adjustments Adapt main to new build config Add buildscenario to buildconfig Handle build env Renaming, usage of high level config All images build pass on EVG Lint Explicit image type, support custom build_path Replace old by new pipeline in EVG Add documentation Split in multiple files, cleanup WIP, passing builds on staging temp + multi arch manifests Replace usage of sonar Remove namespace Remove pin_at and build_id Copied pipeline, removed daily builds and --exclude
This reverts commit 426e522.
# Conflicts: # build_info.json # scripts/release/atomic_pipeline.py # scripts/release/build/build_info.py # scripts/release/build/build_info_test.py # scripts/release/build/build_scenario.py # scripts/release/build/image_build_configuration.py # scripts/release/build/image_build_process.py # scripts/release/pipeline_main.py
# Conflicts: # scripts/release/atomic_pipeline.py # scripts/release/build/build_info.py # scripts/release/build/build_info_test.py
@@ -13,10 +13,10 @@ export CUSTOM_OM_VERSION | |||
export CUSTOM_MDB_VERSION=6.0.21 | |||
export CUSTOM_MDB_PREV_VERSION=5.0.7 | |||
|
|||
export AGENT_VERSION=12.0.33.7866-1 | |||
export AGENT_VERSION=12.0.34.7888-1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this had to change, because the previously used agent version does not appear in release.json
and there is no way to rebuild it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should later change BASE_REPO_URL_SHARED
to use 268558157000.dkr.ecr.us-east-1.amazonaws.com/staging
when we have staging images already
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
q: When would this be and how would we trigger the change then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
q: Are we going to use staging registry the same way we were using ECR /dev
before ?
Does it mean we will push to staging with both tags: the commit sha and latest
?
(just for my understanding, but I think it makes sense)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I understand, please correct me if I'm wrong, latest
images from /dev
were used for local testing, so we can reuse most recent images. Previously the latest
tag was added when the image was built for master commits. To preserve existing behaviour we are going to add latest
tag also when we merge to master (staging build), but those images will land now in /staging
repositories.
Because of this we will need to change our scripts/dev/contexts/local-defaults-context
to use \staging
base repository instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good to me ! Thanks for clarifying :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I'll let @mircea-cosbuc resolve the thread as he commented as well)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
q: When would this be and how would we trigger the change then?
@@ -28,7 +28,7 @@ def infer_scenario_from_environment(cls) -> "BuildScenario": | |||
scenario = BuildScenario.RELEASE | |||
logger.info(f"Build scenario: {scenario} (git_tag: {git_tag})") | |||
elif is_patch or is_evg: | |||
scenario = BuildScenario.PATCH | |||
scenario = BuildScenario.STAGING |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
q: The PR is ready for review. Are those comments meant to be addressed before merging?
f"Building {image_full_uri} for platforms={build_configuration.platforms}, dockerfile args: {build_args}" | ||
) | ||
tags = [f"{build_configuration.registry}:{build_configuration.version}"] | ||
if build_configuration.latest_tag: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible to handle tags as a list in the build configuration instead of treating latest
as a special case ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for latests yes, but not for the olm
tag where we will have a dynamic timestamp suffix. Because of this I've chose the bool rather than array
@@ -28,7 +28,7 @@ def infer_scenario_from_environment(cls) -> "BuildScenario": | |||
scenario = BuildScenario.RELEASE | |||
logger.info(f"Build scenario: {scenario} (git_tag: {git_tag})") | |||
elif is_patch or is_evg: | |||
scenario = BuildScenario.PATCH | |||
scenario = BuildScenario.STAGING |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
when building something new we should keep testability in mind - I think if we need to hardcode this - this means we forgot something as part of the planning
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agree! Reverted the change and we can think how to test this properly
STAGING_REPO_URL="268558157000.dkr.ecr.us-east-1.amazonaws.com/staging" | ||
COMMIT_SHA_SHORT=$(git rev-parse --short=8 HEAD) | ||
|
||
if [ "${is_patch:-false}" = "true" ]; then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should have a way to test this change without doing these hacks to verify it. Otherwise, we will run into the same problem like the last pipeline
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agree! Reverted the change and we can think how to test this properly
# Conflicts: # scripts/release/tests/build_info_test.py
Summary
PR integrates
staging
build scenario withatomic_pipeline.py
and the e2e tests.staging
repositories are created in AWS ECR under/staging
dir. List of newstaging/
repositories:Example AWS page with details:
Additional changes:
latest
tag for staging builds. This is used for local testingmongodb-enterprise-ops-manager
repository tomongodb-enterprise-ops-manager-ubi
(which is used in e2e tests and productionProof of Work
Building all images is passing -> https://spruce.mongodb.com/version/689a0407e7099d000753a536/tasks?sorts=STATUS%3AASC%3BBASE_STATUS%3ADESC
Example image stored together with signature (latest tag is mutable)-> https://us-east-1.console.aws.amazon.com/ecr/repositories/private/268558157000/staging/mongodb-kubernetes-init-database?region=us-east-1
Hacked the build_scenario.py and evg-private-context to force
staging
scenario and make e2e test use the staging paths. Patch with all tests succeeding -> https://spruce.mongodb.com/version/689c67f0ccbf5100079e1e00/tasks?sorts=STATUS%3AASC%3BBASE_STATUS%3ADESCChecklist
skip-changelog
label if not needed